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(57) Abstract 

A computer implemented method, uniquely programmed computer system, and article of manufacture embodying a computer readable 
program means allow a customer on an external network (310) to initiate an authorized business transaction utilizing internal business 
resources (330) on an internal networic (320) without violating security firewalls (300). Specifically, the method directs an internal computer 
system (320) to allow an external computer system (310) to initiate a transaction request (2) using internal resources (330) without violatmg 
a security firewall (300) between the internal computer system (320) and the external computer system (310). The method includes a 
first step of auihenticaUng a connection initiated by the internal computer system (320) between the internal computer system (320) and 
the external computer system (310). thereby establishing an authenticated connection. The second step includes calling by the external 
computer system (310) a transaction request (2) received by the external computer system (310). In response to calling the transaction 
request (2). the third step includes creating by the extemal computer system (310) a string comprising the transaction request (2). arguments, 
and process enviiwunent variables for executing the transaction request (2). The fourth step includes transmitting by the external computer 
system (310) the string to the internal computer system (320) through the authenticated connection. The fifth step includes verifying by the 
internal computer system (320) the transaction request (2). The sixth step includes recreating by the internal computer system (320) the 
original pnx«ss envirxmment. The final step includes executing by the internal computer system (320) the transaction request (2), thereby 
generating an output. 
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SBCURED GATEWAY INTBRPACB 

Field of the invention 

The present invention relates to secured gateway interfaces for 
networks and, more particularly, but without limitation, to a secured 
gateway interface for allowing an external network user to initiate an 
authorized transaction utilizing internal resources without violating 
security firewalls. 

Background informarion and D PscriDtion of the Related Art 


Fig 1 illustrates a prior art secured gateway interface (SGI) 9 
having external server 4 (e.g., hypertext transfer protocol daemon HTTPD) 
15 for processing user/customer requests 2 from anyone on an external network 

(e.g., the INTERNET) and internal server 7 for processing requests from 
anyone on an internal network (e.g., anyone working for a particular 
corporation) and internal databases 8, SGI 9 further includes firewall 6 
for preventing external initiation of internal transactions on internal 
databases 8. Accordingly, firewall 6 prohibits external customers from 
initiating a direct connection to the internal network (i.e., internal 
server 7 and internal databases 8) . This restriction prohibits valid 
^j.^j^s^c:tions, such as product and service purchase requests, because 
customers simply cannot initiate an internal transaction from the external 
25 network. 

A conventional solution to the above described problem entails 
opening a specific port (e.g., port 84) in firewall 6 to inbound traffic. 
However, this solutaon clearly leaves the internal network subject to 

30 external attack. Another solution places all required resources (e.g., 

databases 8) on external server 4. However, this solution continues to 
prohibit execution of internal transactions. Further, external server 4 
may not have enough storage to retain all required resources or the 
resources may be too confidential to be placed on the external server 

35 (e.g., customer data), limiting the services that can be provided. 

Accordingly, there is great demand for a technique that allows a 
customer to initiate an authorized business transaction utilizing internal 
business resources without violating security firewalls. 

Disclosure of yhe invention 

Accordingly, a computer implemented method, uniquely programmed 
computer system, and article of manufacture embodying computer readable 
program means allow a customer on an external network to initiate an 
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authorized business transaction utilizing internal business resources on 
an internal network without violating security firewalls. 

Specifically, the method directs an internal computer system to 
5 allow an external computer system to initiate a transaction recjuest using 

internal resources without violating a security firewall between the 
internal computer system and the external computer system. The method 
includes a first step of authenticating a connection initiated by the 
internal computer system between the internal compucer system and the 

10 external computer system, thereby establishing an authenticated 

connection. The second step includes calling, by the external computer 
system, a transaction request received by the external computer system, 
in response to calling the transaction request ;cn, the third step includes 
creating, by the external computer system, a string comprising the 

15 transaction request and process environment variables for executing the 

transaction request. The fourth step includes transmitting, by the 
external computer system, the string to the internal computer system 
through the authenticated connection. The fifth step includes verifying, 
by the internal computer system, the transaction request. The sixth step 

20 includes recreating, by the internal computer system, the original 

process environment. The final step includes executing, by the internal 
computer system, the transaction request, thereby generating an output. 

Therefore, it is an object of the invention to create a secured 
25 gateway interface that is transparent to the user and the actual 

transaction program. 

It is another object to allow a user to validly initiate a 
transaction through a firewall to an internal network using internal 

3 0 resources. 

It is still another object to allow the user to initiate only a 
valid set of authorized transactions. 

35 It is yet another object to securely authorize a connection between 

an internal computer system and an external computer system before the 
external computer system receives transaction requests from users. 

It is a further object to store transaction programs inside the 
40 firewall without having to modify them. 

Brief Description of the Dra wings 

The invention will now be described, by way of example only, with 

4 5 reference to the accompanying drawings, in which: 
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Fig. 1 illustrates a block diagram of a conventional network system 
for use in implementing the present invention; 

Fig. 2 illustrates a representative hardware configuration for 
implementing the present invention; 

Fig. 3 illustrates a block diagram of a secured gateway interface 
(SGI) according to the preferred embodiment; and 

Fig. 4 illustrates a more detailed process flow diagram of the SGI 
previously illustrated in Fig. 3. 

Detailed Description of the in vention 

The preferred embodiment includes a computer - implemented method, a 
uniquely programmed computer system, and a memory embodying detailed logic 
for directing an internal computer system to allow an external 
user/customer to initiate an authorized business transaction utilizing 
internal business resources without violating security firewalls. 

The present invention is. practised on a computer system illustrated 
in Fig. 2. Computer system 100 includes central processing unit (CPU) 
10, such as an IBM's PowerPC 601 or Intel's 486 microprocessor for 
processing cache 15. random access memory (RAM) 14, read only memory 16, 
and non- volatile RAM (NVRAM) 32. One or more disks 20, controlled by I/O 
adapter 18, provide long term storage. A variety of other storage media 
may be employed, including tapes, CD-ROM, and WORM drives. Removable 
storage media may also be provided to store data or computer process 
instructions. (IBM and Power PC are trademarks of International Business 
Machines Corporation and Intel is a trademark of Intel Corporation) . 

Instructions and data from the desktop of any suitable operating 
system, such as Sun Solaris, Microsoft's Windows NT, IBM's OS/2, or Apple's 
System 7, control CPU 10 from RAM 14. Accordingly, the desktop executes 
from RAM 14. However, in the preferred embodiment, an IBM RISC 
System/6000 runs the AIX operating system, which is IBM corporation's 
implementation of the UNIX operating system. As previously described, 
however, one skilled in the art readily recognizes that other hardware 
platforms and operating systems may be utilized to implement the present 
invention. (Solaris is a trademark of Sun Microsystems Inc., windows NT 
is a trademark of Microsoft Corporation, System 7 is a trademark of Apple 
computer Corporation and OS/2, RISC System/6000 and Aix are trademarks of 
IBM corporation. UNIX is a registered trademark in the united States and 
other countries licensed exclusively through X/Open Company Limited) . 
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Users commxinicate with computer system 100 through I/O devices 
(i.e., user controls) controlled by user interface adapter 22. Display 38 
displays information to the user, while keyboard 24, pointing device 26, 
and speaker 28 allow the user to direct the computer system. 
5 Communications adapter 34 controls communications between this computer 

system and other processing units connected to a network. Display adapter 
36 controls communications between this computer system and display 38. 

Fig. 3 illustrates a block diagram and process flow of a secured 
10 gateway interface (SGI) in accordance with the preferred embodiment. The 

SGI resides on a pair of servers 310 and 320, each being implemented on a 
computer system 100 (see Fig. 1) . External server 310 resides outside 
firewall 300, while internal server 320 resides inside firewall 300. 
Firewall 300 is implemented using any suitable conventional firewall that 
15 prevents external transactions from passing through it to internal server 

320. in the preferred embodiment, firewall 300 is a network router (e.g., 
Cisco router) . However, one skilled in the art readily recognizes that 
firewall 300 could reside within internal server 320. 

20 External server 510 manages communication with users /customers on an 

external network, such as the INTERNET. However, one skilled in the art 
realizes that any type of communication protocol could be used, such as 
SNA or X.25 on any public or private network. Internal server 32 0 manages 
communication of internal resources (e.g., database 330) on an internal 

25 network, such as an internal corporate information network. External 

server 310 runs an outside daemon 312, while internal server 32 0 runs an 
inside daemon 3 22, thereby enabling communication across firewall 300. A 
daemon is a long running computer program that waits for external events 
and executes a predefined series of actions whenever those events occur. 

3 0 Daemons listen for service requests and perform them when requested. 

External server 310 also runs daemon 314, which listens for service 
requests from the external network. Internal server 320 includes service 
program 324 for executing the desired internal transaction. Service 
program 324 and in-ernal database 33 0 represent a set of computer programs 
35 that implement a business transaction (described in more detail herein) . 

Fig. 4 illustrates a more detailed process flow diagram of the SGI 
previously illustrated in Fig. 3. External server 310 includes any 
suitable conventional communications protocol daemon 314, cgi-bin 415, 

4 0 sgi_client routine 416, and outside daemon 312. Outside daemon 312 

contains client /server software for communicating with sgi_client routine 
416 and inside daemon 322. Sgi.client routine 416 contains client/server 
software for communicating with outside daemon 312. Cgi-bin 415 is a 
directory of software that is executed by daemon 314. Specifically, in 
45 this example, cgi-bin 415 includes example.pl 462, which is a special perl 
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script for communicating with sgi_client routine 416 (described in more 
detail herein) . In the preferred embodiment, daemon 314 is a conventional 
Hypertext Transfer Protocol daemon (httpd) (also commonly known as a web 
server) . 

5 

Internal server 320 includes inside daemon 322, service program 324. 
and cgi-bin 426. Service program 324 communicates with outside daemon 
312, inside daemon 322, and executes cgi-bin routines (e.g., example. pi 
480) . In this example, example.pl 480 communicates with internal 
10 corporate databases (e.g. corporate database 330 in Fig. 3) in order to 

authorize the user/customer and execute the business transaction. 

Before a customer/user can successfully request a transaction at 
410, internal server 320 and external server 310 must properly connect. 

15 To do so, the external operating system executes outside daemon 312, 

identifying nhereto a communication port and location of a password file 
residing on a filesystem (not shown) on external server 310. In turn, 
outside daemon 312 reads an eight character password from the password 
file, creates a socicet at the identified communication port, and listens 

20 at that soc)cet for a connect call from inside daemon 322. Therefore, 

outside daemon 312 assumes the role of a server and waits at 430 for the 
connect call from inside daemon 322, which assumes the role of a client. 
Further, outside daemon 212 creates a soc)cet on a second port (daemon 312 
communication port - 1) and waits for a connection attempt from sgi_client 

25 routine 416 at 432 (described in more detail herein) . 

The internal operating system executes inside daemon 322, 
identifying thereto a communication port for connecting inside daemon 322 
to outside daemon 3 12, the hostname of external server 310, the location 

30 of a password file residing in a filesystem (not shown) in internal server 

320, and the location of a valid service file residing in a filesystem 
(not shown) in internal server 320. In turn, inside daemon 322 reads an 
eight character password from the password file, reads the service file 
and stores a table of valid services in memory, creates a socket on the 

35 identified communication port, and finally generates a standard connect 

call at 450 across firewall 300 to outside daemon 312, which is listening 
at 430. Because the connection is being initiated from an internal 
server, firewall 3 00 permits the connection. 

4 0 After inside daemon 322 and outside daemon 312 connect, inside 

daemon 322 and outside daemon 312 must properly authenticate each other. 
TO do so, inside daemon 322 initiates a call to the internal operating 
system to retrieve a current timestamp, transmits the timestamp to outside 
daemon 312, and waits for an authentication string in reply. Outside 

45 daemon 312 receives nhe timestamp and creates the authentication string by 
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mangling (altering, described below) its eight character password with the 
times tamp provided by inside daemon 322, encri-pting this mangled character 
string with a standard UNIX crypt command (or any suitable encryption 
algorithm, such as DES) , and then transmitting the resulting 
5 authentication string to inside daemon 322 at 431. The following C code 

illustrates the process of mangling the eight character password with the 
timestamp. This "create_auth" code requires three arguments - the first 
is the timestamp (i.e., auth_time) , the second is the password (i.e., 
"cred", which is a pointer to the password), and ihe third is a buffer to 
10 store the generated authentication string: 


int create^auth (cime_t, char • cred, char ♦ pJ 
15 { 

char bufOl; /• temporary buffer •/ 

int i ; 

bzero (buf, aizeof (buf 1 i : /* clear buffer •/ 
20 atrcpy tbuf , cred) ; /* load buffer with password •/ 

/* mangle each character of the buffer */ 

for (i « 0;i < e-.i*-*') i 
25 buf(l} (auth.tiine 0177); /*logically ANDing timestamp, then 

exclusive ORing result with each 
character in bufrer: with each 
i teration 

modifying the timestamp •/ 

3 0 auth^time >>=4; /* bit wise move timestamp •/ 

{ 

for (t » 0;i < fi;i**) 

if (bufli! 0) /♦ since a valid character string cannot contain 
a NULL. Chang all NULLS to 1 */ 

35 buffij = 1; 

strcpy (p. crpyt (buf. -aa") + 2); /• encrypc buffer using aa for 

the key • ■ 
/* skip iirsc two characters of 

4 0 encrvTCicn result (which is the 

key aa) • 

/* copy the encryption result to user 
supplied buffer pointed to by P */ 

4 5 return 0; 

) 

inside daemon 322 liJcewise mangles its password with the timestamp, 
encrypts it, and compares it with the authentication string provided by 

50 outside daemon 312. If the authentication strings match, the process is 

reversed and outside daemon 312 li)cewise authenticates inside daemon 322 
(i.e., obtain a new timestamp from the external operating system, transmit 
the timestamp to inside daemon 322, inside daemon 522 mangles its password 
with the new timestamp, encrypts it, and transmits it back to outside 

55 daemon 312 for validation) . 


This authentication process uses an eight character password that is 
known by both outside and inside daemons 312 and 322, a character mangling 
function randomized by a timestamp, and an encryption process. Because of 


xo 


15 
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the mangling function, the above process produces a different encrypted 
authentication string for each authentication and every transaction. Thi 
significantly reduces its vulnerability to attack because a captured 
authentication string is worthless for any subsequent transaction. 

After inside daemon 322 and outside daemon 312 have authenticated 
each other, inside daemon 322, which previously acted as the client, now 
assumes the role of a server and waits at 452 for outside daemon 312 to 
provide a service string at 453. Outside daemon 312 creates another 
socket on the second specified port and waits (listens) for a connection 
attempt from sgi_client routine 416 at 432. Therefore, outside daemon 312 
assumes a dual role of a pseudo client with respect to inside daemon 322 
(information is passed between them) and a server with respect to 
sgi_client routine 416. 


Daemon 314 is now prepared to accept customer request 410. The 
customer request could be, for example, a transaction to purchase research 
information on a particular stock or money market. At 410, the customer 
decides to execute the following transaction request: 
20 http: //external_server/cgi -bin/example. pl?stockl+stock2 

by clicking on a specific icon or highlighted phrase on the customer's 
system, which is running an http client application user interface. The 
http client user interface typically asks the user for detailed 
transaction information (e.g. which stock or money market) as well as 
25 billing information (e.g. a credit card number) . The user may also be 

required to enter his or her userid and password if the requested service 
is only provided to authorized users. 

The format of the transmitted user input depends on the type of 

3 0 Hyper Text Markup Language (HTML) form used to implement the transaction. 

There are two types of conventional HTML forms: A "GET" form places all 
user input on the command line. Therefore, stockl, stock2 and any other 
user input would become part of the command line: 

35 . . ./cgi -bin/example. pl?3tockl-^stock2+chargecardnumber-t.expdate 

However, because the command line will be transmitted across the 
network in clear text, it is not advisable to transmit the customer's 
charge card number and expiration date across the network. Therefore, the 

4 0 "PUT" type of HTML form with encryption is used so that the charge card 
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number and expiration date are safely sent across the network. After 
providing all of this information, the http client application sends the 
request via http to external server 310 at 410. 

At 460, daemon 314 authenticates the customer's password according 
to a commonly known and installed HTTP authentication technique (e.g., 
encrypting the customer's password with a standard UNIX crypt command and 
comparing the result with a password entry in an http password file 
residing in daemon 314). If the userid and password are valid, at 461, 
daemon 314 recognizes the "PUT" form, automatically decrypts the character 
stream, and creates an appropriate UNIX process environment. Daemon 314 
contains a conventional, commonly known http configuration file (not 
shown) for creating a standard UNIX process environment, including PATH, 
USERNAME, LOGNAME, and AUTHTYPE variables. Later, httpsvc 470 recreates 
this process environment at 471 (described herein) . Once the process 
environment has been created, daemon 314 executes example.pl 462 (which 
should reside in cgi-bin 415), transmitting thereto any required arguments 
(e.g. stockl and stock2) and user input to a standard input stream of 
example.pl 4 62 . 

Assuming that example.pl 462 does reside in cgi_bin 415, if firewall 
300 did not exist, example.pl 462 would directly communicate with internal 
database 330 (see Fig. 3) and perform the desired transaction. However, 
because firewall 300 does exist and prevents example.pl 462 from directly 
communicating with internal database 33 0, example.pl 462 is not the actual 
transaction progra.m. Rather, the actual transaction program resides in 
cgi-bin 426 as example.pl 480, which is inside firewall 300. Accordingly, 
cgi-bin 415 contains "special" perl scripts (e.g., example.pl 462) that 
are executed using the same command that would execute the actual 
transaction programs residing in cgi-bin 426. Alternatively, when 
external server 310 provides many services, each of which will require a 
"special" perl script to call sgi_client routine 416 in the same manner, 
example.pl 462 may be a symbolic link (i.e., an indirect filename 
reference) to a single perl script residing in cgi-bin 415. Importantly, 
the requests available to the customer are limited to the perl scripts and 
corresponding transactional programs residing in cgi_bin 415 and cgi_bin 
426, respectively. 

The perl script example.pl 462 places all arguments passed to it 
from daemon 314 into the process environment (e.g. SGIARGl=stockl ; 
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SGIARG2=scock2) . places its name (the name by which it was called, in this 
case example. pi) into the process environment (e.g. SGICMD=example.pl) . 
executes a UNIX env command (which dumps the process environment 
variables) and finally places all the process environment variables into a 
5 header string. The header string now appears as, for example: 

"PATH=/bin: /usr /bin\nAUTHTyPE=PEM\nUSERNAME=JohnDoe\nSGIARGl=StOC}cl \nSGIAR 
G2=stock2\=nSGICMD=example.pl") . 

XO Next, at 463, perl script example.pl 462 calls the external 

operating system to retrieve the designated second port (daemon 312 
communication port + 1), executes sgi_client routine 416, transmitting 
thereto the type of service requested (e.g. httpsvc) , the designated 
second port, the external server hostname, the header string, and the 

15 customer's userid. Exampie.pl 462 also transmits as standard input any 

standard input character stream (e.g., the text of user input) to 
sgi.client routine 4 16. Later, example.pl 462 will pass any output 
received from the sgi_client routine 416 to daemon 314 at 469. 

20 When sgi_client routine 416 executes using the information 

transmitted to it at 463, sgi_client routine 416 establishes an 
authenticated connection to outside daemon 312. to do so, at 417, 
sgi_client routine 4 15 reads an eight character password from a private 
client password file (not shown) residing on external server 310 and 

25 establishes a connection to outside daemon 312 at the designated second 

port, which is listening at 422 from the second soc)cet connection. At 
433, outside daemon 312 creates a copy of itself and executes it (e.g. a 
UNIX process for)c) . The parent process gives the socket connection to the 
child process and returns to 430 to listen for another call from inside 

3 0 daemon 322. 

At 434, the child process authenticates sgi_client routine 416. To 
do so, outside daemon 312 also reads an eight character password from a 
private client password file (not shown) residing on external server 310. 

35 Outside daemon 312 initiates a call to the external operating system to 

retrieve a current timestamp, transmits the timestamp to sgi_client 
routine 416 at 432, and waits for an authentication string in reply. 
Sgi_client routine 416 receives the timestamp and creates an 
authentication string by mangling its eight character password with the 

40 timestamp provided by outside daemon 312, encrypting this mangled 
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character string with a standard UNIX crypt command, and then transmitting 
the resulting authentication string to outside daemon 312 at 434. Outside 
daemon 312 likewise mangles its password with the timestamp, encrypts it, 
and compares it with the authentication string provided by sgi_client 
routine 416. if the authentication strings match, sgi_client routine 416 
is authenticated. 

At 419, if authentication is successful, sgi_client routine 416 
transmits the type of service requested to outside daemon 312. in this 
example, sgi_client routine 416 always requests an HTTP service because 
sgi_client routine 416 was indirectly called by http daemon 314. The 
special perl script (i.e., example.pl 462> previously executed sgi_client 
routine 416 using an argument indicating that the service requested is 
"httpsvc" . Outside daemon 312, in turn, transmits the "httpsvc" service 
request to inside daemon 322 at 435. 

At 452, inside daemon 322 waits for the service request to be 
received from outside daemon 312. At 453, inside daemon 322 receives the 
service request from outside daemon 312, creates a duplicate image of 
itself and executes it (e.g a UNIX process fork) . The parent process 
gives the network socket connection to the child process and returns to 
450 to initiate another connection to outside daemon 312. At 454, the 
child process validates the requested service with the list of valid 
executable services (e.g., httpsvc) residing m the cable in memory and 
the full directory path to those services. if the requested service is 
not within the list of valid services, it will be denied. Accordingly, 
even if an unauthorized user gained access through outside daemon 312 to 
inside daemon 322, he/she would be limited to the services residing within 
the list of valid services. 

If the service request is valid, at 455, inside daemon 322 calls a 
UNIX exec command (i.e., overlays itself with the new service program and 
executes) the requested service and gives the network socket connection to 
httpsvc 470, Httpsvc 470 adds one additional environment variable to the 
process environment, which is the name of outside daemon 312. The SGI 
adds the additional environment variable so that example.pl 480 can, if 
needed, determine that the SGI executed example.pl 480, rather than http 
daemon 314. 
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As a side note, outside daemon 312. inside daemon 322, sgi_client 
routine 416. and httpsvc 4 70 each have accounting and error logging files. 
Each have debugging and trace arguments that cause differing amounts of 
information to be placed in the error and accounting logs. In addition, if 
5 the tracing argument is set by sgi_client routine 416. then outside_daemon 

312. inside daemon 322, and httpsvc 470 will all trace that particular 
transaction in their respective error logf iles. regardless of how tracing was 
set as each was originally executed. 

10 At 436. outside daemon 312 transmits the previously created header to 

service program 324. which receives it at 471. In response, service program 
324 parses the header (which contains the original process environment 
variables) into variable=value strings and recreates the original process 
environment defined in example.pl 462. Service program 324 determines the 

15 appropriate program to call in cgi-bin 426 from the header variable 

SGICMD=example.pl. creates communication channels (e.g. pipes) for 
communicating with example.pl 480. and calls example.pl 480 at 472 . At 437, 
outside daemon 312 transmits the standard input character stream (e.g.. text) 
to service program 324. At 473, service program 324 transmits the text to 

20 the standard input of example.pl 4 80. 

At this points because service program 324 recreated the original 
process environment at 471 (which was originally created at 462), example. pi 
480 believes it is being executed at 472 by http daemon 314, rather than the 

25 SGI (although optionally it can determine that the SGI called it from the 

additional environment variable added to the header by httpsvc 470) . 
According, the SGX is transparent to both the customer, http daemon 314, and 
the actual transaction program residing in example.pl 480. Therefore, 
neither http daemon 314 nor the transaction program residing in example.pl 

30 480 need be altered. 

All the information is now present for example.pl 480 to execute the 
internal transaction on database 330 at 481. Once the transaction is 
complete (whether successful or not), at 481, the output from the transaction 
35 is returned to the customer. At 482. example.pl 480 receives the output from 

the transaction and transmits it to pipe 474 of service program 324. At 474, 
service program 324 transmits the output to outside daemon 312. At 438, 
outside daemon 312 transmits the output to sgi_client routine 416. At 464, 
sgi_client routine 416 transmits the output to the special perl script 
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example. pi 462. At 465, example. pi 462 transmits the output to daemon 314. 
At 4 66 r daemon 314 transmits the output to the customer. 

Accordingly, a customer initiated transaction can be securely 
5 transmitted from daemon 314 to outside daemon 312, from outside daemon 312 

to inside daemon 322 for validation at 454 and processing at 481, and finally 
the output returned to the customer at 466. The customer request and text 
are made available through firewall 300 to the internal transaction 
processing, all under the complete control of the SGI, yet completely 
10 transparent to the customer. Because inside daemon 322 performs 

authentication at 451, strictly enforces the services available to external 
network at 454, and optionally performs user authorization at 481, compromise 
of external server 310 poses a very minimal internal security risk and in no 
way compromises the internal network. 

15 

Using this particular embodiment, existing http servers can implement 
SGI with little or no modifications to existing cgi-bin commands. The SGI 
is completely hidden and will automatically support even sophisticated http 
servers. One can add additional security and support for business 

20 transactions with little modification to the current http server. Because 

the transactions (programs like example.pl) available to the external network 
are limited to the perl scripts and transaction programs residing in cgi-bin 
415 and cgi-bin 426, respectively, and because internal server 320 would 
normally be under strict corporate control and not easily modified by 

25 internal developers, the SGI also makes it difficult for internal developers 

to make internal transactions available to external customers without 
corporate review and consent. 

While the invention has been shown and described with reference to 
30 particular embodiments thereof, it will be understood by those skilled in the 

art that the foregoing and other changes in form and detail may be made 
therein without departing from the spirit and scope of the invention, which 
is defined only by the following claims. For example, an alternative 
embodiment incorporates the functionality of sgi_client routine 416 and 
35 outside daemon into daemon 314. This would provide greater performance, but 

would make the httpd implementation proprietary and improvements thereto hard 
to incorporate. 


40 
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CLAIMS 

1. A method for directing an internal computer system (320) to allow an 
external computer system (310) to initiate a transaction request (2) using 
5 internal resources (330) without violating a security firewall (300) between 

the internal computer system and the external computer system, comprising the 
steps of : 

authenticating (451) a connection initiated by the internal computer 
10 system between the internal computer system and the external computer system, 

thereby establishing an authenticated connection; 

calling (461) by che external computer system a transaction request 
received by the external computer system; 

15 

in response to calling the transaction request, creating by the 
external computer system an original process environment containing process 
environment variables, and creating a string comprising the transaction 
request and the process environment variables for executing the transaction 
20 request; 

transmitting (435, 436, 437) by the external computer system the string 
to the internal computer system through the authenticated connection; 

25 verifying (454) by the internal computer system the transaction 

request ; 

recreating (47l> by the internal computer system the original process 
environment; and 


30 


35 


executing (472) by the internal computer system the transaction 
request, thereby generating (4 82) an output. 

2. A method as claimed in claim 1, further comprising the steps of: 

(a) reading by the external computer system (310) a first password 
and first communication port; 
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(b) creating by the external computer system a first socket at the 
first communication port and listening at the first socket for 
a connect call from the internal computer system (320) ; 

5 (c) reading by the internal computer system a second password and a 

second communication port; and 

(d) creating by the internal computer system a second socket at the 
second communication port and sending a connect call to the 

10 external computer system through the second socket* thereby 

establishing a connection. 

3. - A method as claimed in claim 1, wherein the authenticating step 
comprises the steps of: 

15 

(e) sending a unique timestamp by the internal computer system (320) 
to the external system (310) through the second socket; 

(f ) mangling by the external computer system the first password with 
20 the received timestamp; 

(g) encrypting the mangled first password with an encryption 
algorithm, thereby creating a first password string; 

25 (h) transmitting by the external computer system to the internal 

computer system the first password string; 

(i) repeating steps (f) through (g) by the internal computer system 
using the second password, thereby creating a second password 
3 0 string; and 

(j) comparing by the internal computer system the first password 
string with the second password string. 

35 4. A method as claimed in claim 3 wherein the mangling step comprises the 

steps of: 

logically ANDing the timestamp with a hexadecimal number 0177 to 
produce a uniejue result; and 
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logically exclusive ORing the unique result with each character of the 
first password, thereby producing the mangled first password. 

5, A method as claimed in claim 3, wherein the encryption step comprises 
the step of : 

encrypting each character of the mangled second password with a key, 
thereby creating the password string. 

6. A method as claimed in claim 1, wherein the calling step comprises the 
steps of: 


sending by an external network the transaction request (2) to the 
external computer system (310), wherein the transaction request contains 
15 input data, arguments, and a command for executing a transaction program; and 

in response to receiving the transaction request by the external 
computer system, defining by a first daemon a process environment containing 
the process environment variables. 


7, A method as claimed in claim 6, further comprising the steps of: 

in response to calling the transaction request (2) by the external 
computer system (310), calling the command; 

in response to calling the command, executing a script, transmitting 
thereto the user input data, arguments, and transaction request; and 

creating by the script the string, wherein the string comprises the 
command, arguments, and the process environment variables for executing the 
transaction request. 

8, A method as claimed in claim 7, further comprising the step of: 

calling by the script a client routine residing in the external 
computer system (310), passing thereto the user input data, a third 
communication port for connecting to a second daemon residing on the external 
computer system, and identifier that identifies the type of transaction 
request (2) , €md the string. 


40 
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9. A method as claimed in claim 8, further comprising the step of: 

in response to receiving a call by the script, authenticating by the 
second daemon the client routine; 

forking by the second daemon, passing the third socket connection to 
a child process, whereby a parent process listens at the first socket 
connection for calls from the internal computer system; and 

in response to authenticating the client routine, transmitting by the 
child process the type of transaction request to a third daemon residing on 
the internal computer system. 

10. A method as claimed in claim 1, wherein the verifying step comprises 
the step of : 

reading by the third daemon a valid services table stored in memory on 
the external computer system; and 

comparing the type of transaction request received from the child 
process with the valid service table, wherein if the type is found in the 
valid service table, the transaction request is verified. 

11. A uniquely programmed system for directing an internal computer system 
{320) to allow an external computer system (310) to initiate a transaction 
request (2) using internal resources (330) without violating a security 
firewall (300) between the internal . co^uter system and the external computer 
system, comprising: 

means for authenticating a connection initiated by the internal 
computer system between the internal computer system and the external 
computer system, thereby establishing an authenticated connection; 

means for calling by the external computer system a transaction request 
received by the external computer system; 


in response to calling the transaction request, means for creating by 
the external computer system an original process environment containing 
process environment variables, and means for creating a string comprising the 
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tramsaction request, the arguments, and the process environment variables for 
executing the transaction request; 

means for transmitting by the external computer system the string to 
the internal computer system through the authenticated connection; 

means for verifying by the internal computer system the transaction 

requests- 
means for recreating by the internal computer system the original 

process environment; and 

means for executing by the internal computer system the transaction 
request, thereby generating an output. 

12. An article of manufacture, comprising: 


a computer usable medium having computer readable program code means 
embodied therein for causing an internal computer system to allow an external 
20 computer system to initiate a transaction request using internal resources 

without violating a security firewall between the internal computer system 
and the external computer system, the computer readable program code means 
in said article of manufacture comprising: 

25 computer readable program means for authenticating a connection 

initiated by the incernai computer system between the internal computer 
system and the external computer system, thereby establishing an 
authenticated connection; 

3 0 computer readable program means for calling by the external computer 

system a transaction request received by the external computer system; 

in response to calling the transaction request, computer readable 
program means for creating by the external computer system an original 
35 process environment containing process environment variables, and computer 

readable program means for creating a string comprising the transaction 
request and the process environment variables for executing the transaction 
request; 
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computer readable program means for transmitting by the external 
computer system the string to the internal computer system through the 
authenticated connection; 

computer readable program means for verifying by the internal computer 
system the transaction request; 

computer readable program means for recreating by the internal computer 
system the original process environment; and 

computer readable program means for execuLing by the internal computer 
system the transaction request, thereby generating an output. 
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